This invention pertains to the field of computer software updating. More specifically, this invention pertains to a system and method for generating and using a stored back-patch to undo the effects of a forward patching.
Some computer software publishers update their software applications (computer programs and data files associated with the programs) frequently. These updates often add new features to the applications as well as remove existing bugs. Several methods are commonly used to update software applications. The simplest of these is to distribute one entire software application to replace an older one. This full update method is simple, but expensive and inconvenient. Typically the software application is distributed on some type of removable media, such as floppy disks or CD-ROMs, which are costly to produce and distribute. The time an end user must wait for the removable medium to arrive and the time it takes for the software application to install itself on a computer system are inconvenient. This inconvenience is compounded where updates occur frequently.
Because of the large size of many software applications it is generally not feasible to distribute full updates over computer networks, such as the Internet. When full updates of larger applications are distributed over a network, they often cause such high loads on servers that other users suffer slow-downs on the network, and the servers have trouble meeting the demands.
In order to bypass many of the problems associated with this type of software updating, some software publishers distribute incremental updates. These incremental updates do not contain entire software applications, but rather they contain that information which is necessary to transform a particular version of a software application to a newer version. As used herein, the word xe2x80x9cversionxe2x80x9d indicates a file or application of a specified state. Among the methods available to perform such incremental software updating is binary patching, performed by programs such as RTPatch, published by Pocket Soft, Inc. A binary patcher changes those binary bits of a computer readable file which are different in a newer version. A binary patcher needs, in addition to the old file, a data file which includes the differences between the two versions. Because most software updates involve changes to only a small portion of a software application, these incremental update data files can be relatively small. The data files distributed for a binary patch incremental update are often less than 1% of the size of a full update, taking advantage of the large amount of redundancy between the two versions.
The use of incremental update methods allows for smaller updates which can be distributed by means which are not conducive to the distribution of full updates, such as distribution over the Internet. The smaller incremental updates also make distribution by floppy disk more feasible where a full update would have required many disks, and an incremental update may require only one.
However, conventional incremental update methods introduce another problem: an incremental update is specifically useful for updating only one particular version of a software application to another particular version. When updates occur frequently, as with virus protection software applications, end users may update from an arbitrarily old version to the newest version, skipping over several previously released versions. An incremental update for the newest version of a software application will generally update only from the most recent version, however. To update from an arbitrarily old version to the most recent version with incremental updates, a user often needs to acquire and apply a number of successive incremental updates.
One solution to this problem has been for software publishers to group a number of incremental update files together into one distribution. Each necessary incremental update is applied, one at a time, to update to the newest version. However, the number of incremental updates may be large, due to the fact that a grouping generally covers a large number of possible versions. The benefits of smaller distributed update files begin to disappear, as the size of the grouped-together incremental updates grows. Lowering the number of update files available increases the amount of data the average user must acquire for an update, since the user will not need all of the incremental updates in a grouping. This method of updating applications can also be cumbersome, as a series of incremental updates needs to be selected from the group and applied to the software application one after another.
Another solution to the problem of incremental update version-specificity has been to create many unique incremental update files which each transform a different previous version to the most current version. Then, only one incremental update is needed by any user. However, where updates are very frequent, this scheme results in a large number of incremental update files to produce, store and maintain for users. In the case of publishers, such as virus-protection software publishers, who might update their applications as often as daily, this can quickly become untenable. The number of files which must be made available with this scheme grows quickly, and makes the mirroring of incremental updates on a local server difficult. For example, in a case where a virus protection software publisher makes new virus definition files available daily, each year""s worth of updates will require approximately 365 incremental update files.
One alternative to the methods described above is the use of xe2x80x9cpushxe2x80x9d technology, in which a server maintains a database of what version each user has. The server then sends the necessary updates to each user, as they become available. This system requires xe2x80x9csmartxe2x80x9d servers, however, to monitor user configurations, to determine what each user needs, and to send the appropriate update information. This results in a server-intensive system which can cause a drain on server resources comparable to that experienced in the full update scheme, when many users are simultaneously requesting full updates. It is preferable to use a system which allows update files to be stored on a xe2x80x9cdumbxe2x80x9d server which simply provides specifically requested files.
In an alternative which addresses these problems, at least one of a sequence of versions of a computer readable file is designated a xe2x80x9chubxe2x80x9d version. Hub updates are made available on a server for updating any previously published hub version to the most recently published hub version. A final update is also made available on the server for updating the most recently published hub version to the current version. A previously published hub version of the file can be used with the two updates to produce a file of the current version. The first update is used to produce the most recent hub version, and the second update is used to produce the current version.
When such an update is carried out, an intermediate version of the file, the most recent hub version, is produced. The file of this hub version is retained locally subsequent to the current version being constructed. The current version is used as an active version, while the most recent hub version is an archive version. The next time an update is carried out, the archive version (being a hub version) can be used with just the two update files to update the active version to the new current version. If there are few hubs, the number of update patches which must be made available is small. For example, if a virus protection software publisher makes new virus definition files available daily, the publisher may designate as hubs those versions which coincide with the first day of each month. Over a year""s worth of updates can be stored on the publisher""s server in the form of thirteen hub updates and one final update. Unlike the case in which large numbers of incremental updates are grouped together to lower the number of files to be maintained, each of the hub updates and the final update can be as small as a typical incremental update. Also, dumb servers can be used to store the updates.
Retaining an archive version of a file or application locally, however, can impose a significant burden on the end user. Because the archive version which is retained will generally be of comparable size to the final version, this method requires on the order of twice as much local storage space for each end user. Conventional compression of the archive version results in some storage space savings, but the storage requirements for some compressed archive versions are still nearly as large as an uncompressed archive version. It would be useful to retain only that information from the archive version which is necessary.
In one embodiment of the present invention, a file of a first state (3.0) is updated to a second state (3.2) through the use of an incremental update (112) which provides the information necessary to construct the file of the second version (3.2) from a file of the first version (3.2). In order to allow for future access to the first version (3.0), without maintaining a copy of the file of the first version (3.0), a back-update file (206) is created. The back-update file (206) provides the information necessary to construct a file of the first state (3.0) from a file of the second state (3.2). After the back-update file (206) has been created and stored, the file of the first version (3.0) can be deleted.